Database systems managing large amounts of data may distribute and/or replicate that data across two or more machines, often in different locations, for any of a number of reasons, including security issues, disaster prevention and recovery issues, data locality and availability issues, etc. These machines may be configured in any number of ways, including as a shared resource pool, such as in a grid computing architecture.
Interaction between client applications and database servers typically includes read operations (read-only queries), write operations (to store data), and update operations that can be conceptualized using a read-modify-write workflow consisting of the following steps:
The client application reads data from the database server (via a query).
The client application applies business logic and derives new or modified data.
The client application writes data back to the database server.
Relational database management system (RDBMS) technology is one of the most predominantly used technologies by application developers to manage state. RDBMS is a complex technology, and, traditionally, developers employing this technology must deal with all the complexity that comes with it. The complexity around operational support of such systems, along with security compliance, change management, and optimization, is often a source of difficulty and/or aggravation for developers. In addition, the high barrier for provisioning and deploying a reliable RDBMS system can significantly impact developer productivity. Furthermore, software owners typically have to spend time to build platform scalability into their applications rather than focusing on their core business of application development. Relational databases systems are also costly and may be difficult to use efficiently, especially when these systems operate in environments with widely varying resource requirements over time.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including, but not limited to.